The previous model where we declare/define builtins based on whether
target supports the generic address space was not able to capture the
full complexity of what we need.

We could see this in the fact that the two targets which we marked as
not supporting the generic AS do in fact support it. The problem is
rather that the target AS they map the generic AS to is the same target
AS mapped to by the private AS.

This problem hasn't properly been made apparent because all builtins we
want to support with the generic AS also have overloads on the private
AS. However, as can be seen in PRs like intel#13428, some targets want to
support generic AS overloads of atomic builtins which don't also have
private AS overloads. It's here that the simple dichotomy breaks down.

This patch splits up the support of the generic AS into:

1. The target doesn't support the generic AS
2. The target supports the generic AS as a distinct target AS
3. The target supports the generic AS mapped identically as the private
   the AS

All of our previous uses of case 1 have been migrated to case 3. These
targets can make use of case 2 in the future to support generic AS
builtins where no private AS builtins are supported.

Note how we hardcode the assumption that the clash is on the private
address space. This is unfortunate but for simplicity as it's the case
for the two targets we care about. It was already being made, but in a
less obvious way. There are ways of loosening this assumption if we ever
needed to but it would currently complicate the code for untested
scenarios.